System, method and apparatus for storage controller having multiple heterogeneous network interface ports

ABSTRACT

A Multiprotocol Storage Controller (MPSC) System on a Chip (SOC) comprising multiple heterogeneous network interface ports, a switch core, a global memory mapper and a frame router. The interface ports capable of interconnecting networks of devices with differing data and signaling protocols and differing number of data and signal lines.

FIELD OF THE INVENTION

A multiprotocol storage controller System on a Chip with multipleheterogeneous network interfaces supporting various interface protocols.

BACKGROUND OF THE INVENTION

The amount of data generated in the world is increasing at a very largerate. Current information technology systems, composed of compute,networking and storage elements are challenged to store and act on thisdata. New standards are being created to move, store and manipulate thedata. New components are also being created to manipulate the data innew ways creating entirely new applications and industries. One of thesenew components is the Graphics Processing Unit (GPU). The GPU wasinitially created to render three dimensional (3D) graphics, which arecomprised of polygons. Offloading graphics processing to high-poweredGPUs is what makes modern gaming possible.

While GPUs excel at rendering graphics, the raw power of a GPU can alsobe used for other purposes. Many operating systems and software programsnow support GPGPU, or general-purpose computation on graphics processingunits. This can improve the overall performance of a computer or otherelectric device. New standards have allowed the very high speedinterconnect of GPGPUs to result in a system capable of executing a verylarge number of parallel instructions. Some very important applicationshave found their way onto GPGPUs and GPGPU networks. These applicationsinclude artificial intelligence (AI), machine learning (ML) andaccelerated databases among others.

With GPGPUs, new performance bottlenecks have appeared in systems whichinclude them. Since bottlenecks limit the amount of data that can beloaded and unloaded from GPGPUs and networks of GPGPUDs, someapplications suffer performance limitations. The problem is exacerbatedsince the GPGPU interconnect standards are different, and usually higherperformance, than compute to GPU interconnect standards. What is neededis a way to move data onto and off of GPGPUs, and any other componentwhich supports a higher speed compute to GPU interface.

BRIEF SUMMARY OF THE INVENTION

Methods, apparatus, systems and products are disclosed for creating theinterconnection of differing networks by a multiprotocol storagecontroller system on a chip.

In one aspect, the system is provided for interconnecting multiprotocoldevices with a multiprotocol storage controller (MPSC) system on a chip(SOC). The MPSC SOC comprises at least a switch and a frame router. Thesystem comprises a first device supporting a first protocol and a seconddevice supporting a second protocol, both coupled to the MPSC SOC andthe switch and frame router within. The MPSC SOC affects the transfer ofdata between the first device and the second device. The MPSC SOC canalso affect the transfer of data between other supported networks.

In yet another aspect of the invention, a method is provided forforwarding data between two devices supporting two different protocolscoupled to a MPSC SOC. The methods consist of receiving data at the MPSCSOC from a first device a first port supporting a first protocol andmapping the address to a second port in the MPSC SOC. The addressmapping performed by a Global Memory Mapper comprised of a memory maptable.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings illustrate only exemplary embodiments of the invention andtherefore do not limit its scope because the inventive concepts lendthemselves to other equally effective embodiments.

FIG. 1 embodies a Multiprotocol Storage Controller (MPSC) SOC andaccompanying components that make up a complete network based storagesolution, utilizing both network based storage and local storageconnectivity.

FIG. 2 provides a high level description of one embodiment of the MPSCSOC. The SOC is providing network connectivity with an Nvidia GPUcomplex via a NVLink™ interface, and can provide, for example,connectivity to an Ethernet interface running a NVMf protocol, a PCIeinterface running OpenCAPI, local storage through a ONFI controller orother protocols as configured.

FIG. 3 describes an embodiment of the Frame Router. The Frame Router isused to determine how to expediently move unique traffic, through theMPSC SOC, with minimum latency. Each of the plethora of uniqueinterfaces provides header information to the Frame Router in which theFrame Router uses to build the necessary data paths.

FIG. 4 describes an embodiment of the Switch. The Switch is used tocreate high speed data paths between unique interfaces. The Switchprovides the necessary protocol for the specific interface, which may ormay not include encapsulation/de-capsulation of data. The Switch isaware of the global address space with the use of a programmable GlobalMemory Mapper function.

FIG. 5 describes the management/configuration interface, which in oneembodiment includes registers that control the MPSC SOC functionsthrough the use of a Management CPU.

FIG. 6 provides an embodiment of the MPSC SOC being utilized within aNvidia GPU complex, connecting directly to the NVLink™ interface of anNVSwitch™ complex. This embodiment includes local flash memory, ascontrolled by one instantiation of the MPSC SOC and NVLink™. A secondinstantiation of the MPSO SOC is connected to the NVLink™ on oneinterface, and to both an Ethernet interface running a NVMf protocol,and a second PCIe interface, running a Gen-Z protocol.

FIG. 7 provides an embodiment of the Ethernet Controller. The EthernetController provides the specific Ethernet interface and the connectivityto the Frame Router and the Switch interfaces. This controller providesthe RDMA and offload engines needed for today's high performancenetworks and is managed by a CPU.

FIG. 8 provides an embodiment of the MPSC SOC providing multiportstorage connectivity using a network interface that providesconnectivity to remote storage, as well as connectivity to other MPSCbased systems. The MPSC SOC is additionally connected to a NVSwitch™complex, and to local storage.

FIG. 9 shows the Global Memory Mapper table that maps addresses from theingress port to the egress port. Both ports may support differentprotocols and/or protocol encapsulations.

FIG. 10 shows the Protocol Encapsulation/Decapsulation table thatcomprises information on the ingress and egress MPSC SOC protocols. Thetable provides information so the MPSC SOC can decapsulate receivedingress data and encapsulate the egress data with the appropriateprotocol.

DETAILED DESCRIPTION OF THE INVENTION Definitions

AI: Artificial Intelligence

AI-proc: Artificial Intelligence processor

ASIC: Applied Specific Integrated Circuit

CPU: Central Processing Unit

DDR: Double Data Rate Random Access Memory

FC-NVMe: NVMe over Fibre Channel

FIFO: First In First Out

Frame: Refers to a window of bytes or bits in a data packet or fromcontiguous data

Gen-Z: Generation Z next generation bus

GPGPU: General Purpose Graphics Processing Unit

GPU: Graphics Processing Unit

iWARP: Internet Wide area RDMA protocol

KVS: Key Value Store, object based application programming interface

PCIe: Peripheral Component Interconnect Express

PHY: Physical layer of the OSI model

MAC: Media Access Controller

MPSC: Multiprotocol Storage Controller

NAND: Not-and flash memory, flash memory made up of NAND gates

NIC: Network Interface controller

NPU: May refer to either a Neuron processing unit or a network processor

NVLink™: Nvidia's proprietary inter-GPU link

NVMe: Non-volatile memory express

NVMe-oF: Non-volatile memory express over fabrics, see below definition

NVMf: Non-volatile memory express over fabrics. May refer to NVMe overTCP

NVMe over iWARP, NVMe over RoCE v2 or NVMe over RoCE v1.

NVSwitch™: Nvidia's proprietary switch to interconnect NVLink™ GPU's

ONFI: Open NAND Flash Interface Specification

OpenCAPI: Open Coherent Accelerator Processor Interface

RAM: Random Access Memory

RDMA: Remote direct memory access

RNIC: RDMA Network Interface Controller

RoCE: RDMA over Converged Ethernet

SOC: System on a Chip

SSD: Solid State Storage Device

FIG. 1 shows a MPSC SOC 3 and accompanying components that make up acomplete network based solution, utilizing both network based storageand local storage connectivity. The MPSC 3 may support zero or more ofthe following interfaces: GPU NVLink™ 16 17, Non-volatile memory express(NVMe) solid state storage device (SSD) 21, PCIe 12 18, Open NAND FlashInterface Specification (ONFI) 8, Ethernet 1. Each interface 1 8 12 1617 18 21 is supported by specialized port protocol block logic containedwithin the MPSC 3. The MPSC 3 is capable of connecting or bridgingbetween two similar or different supported interfaces 1 8 12 16 17 1821. This allows the combining of very high speed protocols and the speedup of the transfer of data between the protocols. For example, data froma GPU 24 2 can be transferred to an NVMe SSD 22 at a high speed by theMPSC 3. This would allow the loading and storing of data from the GPU tostorage without going through a CPU. Another example would be thetransferring of data to and from a GPU 24 2 to high speed Ethernet ports1 9 10 to reach other devices. Still another example would be the highspeed transfer of data between GPUs 24 2 and AI processor 201 andstoring that data directly to NAND flash devices 4 5 6 7 on an ONFIchannel 8. FIG. 1 shows the MPSC 3 directly attached to the GPUs 24 2NVLink™ 16 17, which is an Nvidia proprietary link created to send databetween GPUs at a higher speed than the PCIe interface standard. In thisscenario, the MPSC 3 is capable of transfer of data faster than a CPUconnected to the GPU PCIe interface utilizing faster interconnectstandards.

FIG. 2 provides a high level description of one embodiment of the MPSCSOC 50. The MPSC SOC 50 is providing network connectivity with an NvidiaGPU complex via a NVLink™ interface 51, and can provide, for example,connectivity to an Ethernet interface 55 running a NVMf protocol, a PCIeinterface 57 58 running OpenCAPI, local storage through a ONFIcontroller 61 or other protocols as configured. The MPSC SOC 50 iscomprised of zero or more of the following blocks: frame router 59,Switch Control 60, ONFI controller 61, Ethernet controller 62, PCIecontroller 57 58, NVLink™ controller 56. The frame router 59 performsthe Control Plane 65 data forwarding between two different controllers56 57 58 61 62. The frame router 59 is connected to the controllersthrough signaling lines 63, 66 so the controllers can signal the framerouter than a data frame is ready to be forwarded, identify the type ofdata frame, and the destination of the data frame and set up theconnection 68 through the Switch Control 60. Note that the MPSC SOCregister or memory access from external entities is not shown.

The Switch Control 60 is connected 64 67 to each controller 56 57 58 6162 to affect the transfer of data between the controllers. The SwitchControl 60 is also connected 68 to the frame router 59. This connectionallows the frame router 59 to signal the Switch Control 60 to identifythe source and destination controllers 56 57 58 61 62 to affect the dataflow. The ONFI Controller 61 supports the ONFI protocol and supports oneor more ONFI channels 54. The NVLink™ controller 56 supports the dataand transport layers defined by NVLink™ to connect with other NVLink™high speed interfaces 51. The PCIe controllers 57 58 support the PCIetransports and optionally support standards which utilize the PCIesignaling such as OpenCAPI and GenZ. The Ethernet controller 62 supportsthe Ethernet signaling standards and supports connection to Ethernetdevices 55. The Ethernet controller 62 also supports various protocolswhich utilize Ethernet which may comprise one or more of the following,but not limited to: RDMA, RoCE, NVMf. Each controller 56 57 58 61 62 cansupport differing link speeds and link counts. Shown are example speedsand links. Note that the Switch Control register or memory access fromexternal entities is not shown.

FIG. 3 describes an embodiment of the Frame Router 140 within the MPSC150. The Frame Router 140 is used to determine how to move traffic fromeach source controller 100 101 102 103 104 to each destinationcontroller 100 101 102 103 104, through the MPSC SOC 150, with minimumlatency and maximum efficiency. The Frame Router 140 comprises thefollowing functional blocks: route request 115, route determination 116,path lookup table 117, route response 118, Global Memory mapper 119. TheFrame Router 140 is coupled externally to the Switch Control 141 142 andthe port protocol blocks 100 101 102 103 104. Each of the port protocolblocks 100 101 102 103 104 are connected to the Frame Router throughsignal lines 105 106 107 108 109 110 111 112 113 114. The signal linesprovide one or more of the following functions: frame headerinformation, source port protocol block number, port protocol blockprotocol identification, port protocol block protocol state, routerequest signal, route response signal, frame content information, framepriority information, frame address information. Note that the FrameRouter register or memory access from external entities is not shown.

The Route Request functional block 115 is coupled 143 135 to the SwitchControl 141, the Route Determination block 116 and the port protocolblock request signal lines 130 131. The Route Request block 115 readsroute requests and their associated information and creates a routedetermination signal vector 135. The Route Determination signal vector135 may comprise one or more of the following information fields: sourcecontroller, frame to switch header or portions of the header, congestioninformation from the controller, priority information from thecontroller. The Route Determination block 116 is coupled 136 to the pathlookup table 117 which includes additional information to determine theroute, which may comprise one or more of the following: protocolspecific information based on the port protocol block, information abouthow to connect two different port protocol block protocols, routeinformation based on the type of frame.

The path lookup table 117 determines from the route request whichdestination port protocol controller to route the ingress portcontroller requested data. The path lookup table 117 may compriseregisters or memory with ingress and egress port protocol block pairsfor static data forwarding. The Global Memory Mapper 119 is coupled 145to the Route Determination block 116. The Global Memory Mapper 119receives information about the ingress port protocol block and incomingframe. The Global Memory Mapper 119 may perform some address mappingwhich is passed to the Route Determination block 116. The RouteDetermination block 116 may forward the received information from theGlobal Memory Mapper 119 to the Route Response Block 118 which may inturn forward 144 the information to the Switch Control 142.

The Route Response block 118 is coupled 134 144 to the RouteDetermination block 116, the Switch Core 142 and to each 132 133 portprotocol block 100 101 102 103 104. The Route Response block 118 signals144 the Switch Control 142 to build a source and destination path to thespecific port protocol blocks 100 101 102 103 104 and signals the sourceand destination controllers that the switch path is completed.

FIG. 4 describes an embodiment of the Switch Control 260 within the MPSC280. The Switch Control 260 is used to create high speed data pathsbetween unique interfaces port protocol blocks 200 201 202 203 204. TheSwitch Control 260 provides the necessary protocol and buffering for thespecific interface, which may or may not includeencapsulation/de-capsulation of data 205 206 207 208 209. The SwitchControl 260 comprises one or more of the following functional blocks:Switch Controller 210, Switch Matrix Buffer 211, Protocol encapsulation(encap), decapsulation (decap) and memory buffer 205 206 207 208 209.The Switch Controller 210 is coupled to 230 231 232 the Frame RouterFIG. 3 140 and to the Switch Matrix Buffer 211. The Switch Controller210 signals 255 the Switch Matrix Buffer 211 to create a data path 256257 258 259 261 262 between two port protocol blocks 205 206 207 208209. The Switch Matrix Buffer 211 may comprise one of the following:multi-ported memory switch, switch composed of multiplexors,asynchronous switch.

The Switch Control 260 also comprises one or more Port Protocol Blockscomprising protocol encap/decap and memory buffer elements 205 206 207208 209. The protocol encap/decap function allows the transfer of databetween networks with two different framing protocols. Generally, aframe with a first protocol is received, the protocol, may be theheader, footer or other parts, is removed and a second protocol, whichmay include a header, footer or other parts, is added to the frame.Usually this requires the buffering of one or more portions of theframe. The Port Protocol blocks 205 206 207 208 209 are coupled 256 257258 259 261 262 to the switch matrix buffer 211 and to the 220 221 222223 224 225 226 227 228 229 port protocol blocks 200 201 202 203 204.

FIG. 5 contains an embodiment of the management interface used forconfiguration and monitoring of the MPSC 510. The MPSC 510 is controlledby a CPU 512 over a PCIe 511 Interface. The MPSC 510 is set up andcontrolled by a group of registers called the System Block ConfigurationRegisters 500. The Frame Router Registers 501, the Switch ControlRegisters 502 and the Port Protocol Block Registers are used toconfigure the Frame Router, the Switch and the Ports respectively of theMPSC 510, and all provide status and error information back to the CPU512. The CPU 512 accesses system memory by the System Ram Interface 504.

FIG. 6 contains an embodiment of the MPSC1 611 and MPSC2 612 being usedon a printed circuit board 695 that are providing both internal andexternal access to storage to a GPU complex. This complex is comprisedof GPU1 through GPU10 601-610, an N×N crossbar Switch 625, comprising 1218×18 switches SW613-SW624 and MPSC1 611 and MPSC2 612. Each of theGPU's has a high speed connection 671 to the switch attached directlybelow it, as well as to the remaining 5 switches that reside on the sameside through additional high speed interfaces 670. Each of the switchesare connected directly across to a switch chip directly below it. Eachof the devices also supports a PCIe interface 680 681 for configurationand control. MPSC1 611 is used to provide high speed access to localstorage by providing connectivity into the GPU complex over a number ofhigh speed interfaces 670 671 and to local NAND flash 650-657 through anumber of ONIF channels 660 661.

MPSC2 612 is used to provide high speed access to remote storage byproviding connectivity into the GPU complex over a number of high speedinterfaces 670 671 and to an external Storage Array1 690, over a numberof Ethernet Links 692 while using a storage protocol like NVMf. MPSC2612 additionally provides connectivity to a local coherent Gen-Z Fabric691 over a second high speed interface 693. MPSC1 611 and MPSC2 612 areshown to interconnect a number of high speed protocols and networks inthe diagram but the invention is not limited to the elements shown.

FIG. 7 contains an embodiment of the Ethernet Controller 704 that isused to provide network connectivity to other MPSC's or network devicesover high speed Ethernet links 703. The Ethernet Controller 704 iscomprised of a Phy 719, a MAC 718, a Transport 717, RDMA 716 assist,Offload engines 715, a Buffer 714, a Switch I/F 711, a Frame Router I/F710 and an Ethernet Controller Control 702.

The Ethernet Controller 704 is configured and managed by the EthernetController Control 702, which is comprised of an eCPU 712 and Memory713, which may or may not be local to the Ethernet Controller 704. TheeCPU 712 has access to all the blocks within the controller over controland data paths 720-726.

The Frame Router I/F 710 provides specific control information to theFrame Router about the ingress data coming into the MPSC, and destinedto some other interface, and controls the flow egress data leaving theMPSC. The Switch I/F 711 provides data path connectivity to/from theSwitch Matrix Buffer.

The Buffer 714 is a FIFO memory used for data smoothing into and out ofthe MPSC Switch Matrix Buffer.

The Offload engines 715 are used to provide hardware assist on the datacoming into and out of the MPSC. The particular assist is configured bythe eCPU 712 over an interface 724, which may include CRC calculationsand checks, T10 DIF checks, compression, encryption etc.

The RDMA 716 controller is used to provide hardware assist to somenumber “N” external RDMA connections. Once the RDMA conversation is setup, via the eCPU 712 over interface 725, the RDMA 716 controllerprovides the full hardware support for control and data movement.

The Transport 717, MAC 718 and PHY 719 all work together to provide thenecessary connectivity to another Ethernet device (i.e. configuration ofthe number of interfaces used for the connection, speed of theinterface, the particular Transport which may comprise one or more ofthe following: RDMA, RoCEv2, UDP, TCP, etc). These blocks are configuredwith the eCPU 712 over an interface 726. Although an Ethernet controlleris described, an InfiniBand controller can easily be substituted.

The Ethernet Controller 704 may perform encapsulation and decapsulationof Ethernet frames sent and received, respectively, over the Ethernetinterface 703. In one aspect, an incoming data packet from another MPSCinterface, such as the PCIe interface, contains address spaces andtransaction types, such as memory or I/O read and write. The EthernetController 704 may encapsulate the PCIe address spaces and transactiontypes in another protocol, such as RDMA, after the address from the PCIepacket is mapped by the global memory mapper, FIG. 3 119. The result isthe transmission of an Ethernet frame comprising the read or writecommand from the original PCIe data, the address from the PCIe packetmapped to the address range of the entity coupled to the Ethernetnetwork 703 along with optional data if the transaction type is a PCIewrite.

FIG. 8 contains an embodiment of the MPSC 803 804 being used in a GPUsystem 860 861 communicating through a Network 802 over their respectiveinterfaces 819 820, that connects to Remote Storage 800 and RemoteClients 801 on one side, and to local storage 805 806 over a high speedinterface 821 822 and to a NVSwitch™ 807 808 using a high speed NVLink™interface 817 818, which provides the data to the GPU's 809-816.

FIG. 9 shows the Address Map Table 900 within the Global Memory Mapperfunctional block, FIG. 3 119. The Address Map Table 900 maps addressesfrom an MPSC SOC ingress port to the egress port, FIG. 1, 8 12 16 17 1821. Both ports may support different protocols and/or protocolencapsulations, FIG. 2 56 57 58 61 62. The Global Memory Mapper FIG. 3119 maps data from one ingress port protocol to another egress portprotocol. The Global Memory Mapper FIG. 3 119 is coupled with the SwitchController and each supported port protocol block FIG. 4 205 206 207 208209. The Global Memory mapper FIG. 3 119 reads the ingress port protocoland maps the received address. The Global Memory Mapper FIG. 3 119comprises a Memory Map Table FIG. 9 900 which comprises one or more ofthe following elements: Ingress Interface type or protocol 903, MemoryStart Address 904, Memory End Address 905, Egress Interface type orprotocol 906, Mapped Memory Address Start 907, Mapped Memory Address End908. The Memory Map Table 900 is used to map the address space fromingress based data and ports to egress addressing and ports.

The MPSC SOC may optionally map the address from the ingress port to theegress port. The memory translation algorithm starts when the GlobalMemory Mapper FIG. 3 119 is signaled that data is received from aningress port. The address from the incoming frame is read by the GlobalMemory Mapper FIG. 3 119. The ingress address may be checked with theMemory End Address 905 value in the Memory Map Table FIG. 9 90 that itis a valid and inbounds address. An offset from the ingress start memoryaddress is calculated by using the Memory Map Table 900 IngressInterface type or protocol table location 903 along with the MemoryStart Address table location 904. The offset is calculated bysubtracting the received ingress frame address from the Memory Map Table900 Memory Start Address 904 for this Interface type or protocol 903.The offset is then added to the egress Mapped Memory Address Start tablelocation 907. The resulting address may be then checked for out ofbounds conditions using the egress Mapped Memory Address End tablelocation 908. The result is an address that is mapped from an ingressaddress range to an egress address range.

FIG. 10 shows the Protocol Encapsulation/Decapsulation (PED) Table 1000.The table may be located in the specific Protocol Controllers FIG. 3 100101 102 103 104, the Switch Control FIG. 4 260 Protocolencapsulation/decapsulation buffers 205 206 207 208 209, or in the FrameRouter FIG. 3 140. The PED Table 1000 can be located in the specificProtocol Controllers such as the Ethernet Controller FIG. 3 101 FIG. 4201 204. If the PED Table 1000 is located in the Ethernet ControllerFIG. 7 704 the table lookup and protocol encapsulation/decapsulation maybe implemented in software by the eCPU 712 or in hardware by the OffloadEngines 715. The PED Table 1000, contains both ingress and egressinformation, which may comprise: port number, ingress protocol, egressprotocol. Incoming data from the Ethernet link FIG. 7 703 may compriseone or more of the following Ethernet frame fields: MAC address, RDMAaddress, IP address, TCP address, UDP address. The PED Table 1000 showsthree rows, the first 1010 1011 1012 1013, the second 1020 1021 10221023, the third 1030 1031 1032 1033. Once enough of the Ethernet frameis received, a lookup of the PED Table 1000 occurs to determine thespecific table row. Once the PED Table 1000 row is selected, thespecific egress columns in the row determine the protocol encapsulation.The data is then forwarded to the egress port using the Frame RouterFIG. 3 140 and the Switch Control FIG. 4 260. The NA's 1011 1021 0133specify ‘not applicable’. Note that the PED Table, encapsulation anddecapsulation functions can be centralized or distributed.

Although the foregoing invention has been described in some detail byway of illustration and example for purposes of clarity andunderstanding, it may be readily apparent to those of ordinary skill inthe art in light of teachings of this invention that certain changes andmodifications may be made thereto without departing from the spirit orscope of the appended claims

We claim:
 1. A system for interconnecting multiple devices via amultiprotocol system, comprising: a multiprotocol System On Chip (SOC),a switch core, the switch core creating data paths between attacheddevices, a first port protocol block and a second port protocol block,each protocol block comprising a memory buffer for incoming data andoutgoing data, protocol encapsulation and decapsulation functions, thefirst port protocol block and the second port protocol block coupled tothe switch core, a global memory mapper, the global memory mappercoupled to the switch core and coupled to the first port protocol blockand the second port protocol block, the global memory mapper,comprising: an address mapping table, the address mapping tablecomprising: one or more rows in the table, wherein each of the rowscomprises: an ingress protocol, an ingress start memory address, and anegress start memory address, a first device coupled to the multiprotocolSOC, a second device coupled to the multiprotocol SOC, whereby the firstdevice sends data to the first port protocol block of the multiprotocolSOC, the first port protocol block sends a first address of the data tothe global memory mapper, the global memory mapper calculates a secondaddress using the offset of the first address relative to the ingressstart memory address and the egress start memory address correspondingto the second port protocol block, the global memory mapper sends thesecond address to the second port protocol block, the second portprotocol block sends the data to the second device according to thesecond address, the protocol supported by the first port protocol blockis different from the protocol supported by the second port protocolblock.
 2. The system of claim 1 whereby each protocol block supports oneof the following interfaces: NVLink, PCIe, Ethernet, RDMA, RoCE v2, RoCEv1, InfiniBand, OpenCAPI, Gen-Z, iWARP, FC-NVMe, ONFI.
 3. The system ofclaim 1 whereby the address mapping table comprises one or more of thefollowing: ingress memory stop address, egress memory stop address,egress protocol type, egress protocol information, ingress memory startaddress, egress memory start address, ingress protocol information. 4.The system of claim 1 whereby the multiprotocol system is containedwithin a single ASIC.
 5. An apparatus for interconnecting multipledevices via a multiprotocol system, comprising: a switch core, theswitch core creating data paths between attached devices, a first portprotocol block and a second port protocol block, each protocol blockcomprising a memory buffer for incoming data and outgoing data, protocolencapsulation and decapsulation functions, the first port protocol blockand the second port protocol block coupled to the switch core, a globalmemory mapper, the global memory mapper coupled to the switch core andcoupled to the first port protocol block and the second port protocolblock, the global memory mapper, comprising: an address mapping table,the address mapping table comprising: one or more rows in the table,wherein each of the rows comprises: an ingress protocol, an ingressstart memory address, and an egress start memory address, whereby datais received by the first port protocol block, the first port protocolblock sends the address of the data to the global memory mapper, theglobal memory mapper looks up the address in the address mapping table,the global memory mapper calculates the address for the second portprotocol block, the global memory mapper sends the newly calculatedaddress to the second port protocol block, the protocol supported by thefirst port protocol block is different from the protocol supported bythe second port protocol block.
 6. The system of claim 5, whereby eachprotocol block supports one of the following interfaces: NVLink, PCIe,Ethernet, RDMA, RoCE v2, RoCE v1, InfiniBand, OpenCAPI, Gen-Z, iWARP,FC-NVMe, ONFI.
 7. The system of claim 5, whereby the address mappingtable comprising one or more of the following: ingress memory stopaddress, egress memory stop address, egress protocol type, egressprotocol information.
 8. The system of claim 5, whereby themultiprotocol system is contained within a single ASIC.
 9. A method fortransferring data between at least a first device coupled to a firstport protocol block in a Multiprotocol Storage Controller (MPSC) SystemOn Chip (SOC) to a second device coupled to a second port protocol blockin the MPSC SOC, the MPSC SOC comprising at least a switch controller,the first port protocol block and the second port protocol block and aglobal memory mapper, the method comprising: receiving data from saidfirst device to the first port protocol block; mapping an address fromthe incoming data in the first protocol block to an address for thesecond port protocol block by the global memory mapper; and sending thedata with the newly mapped address to said second device by the secondport protocol block, wherein the protocol supported by the first portprotocol block is different from the protocol supported by the secondport protocol block, wherein each of the first port protocol block andthe second port protocol block comprises: a memory buffer for incomingdata and outgoing data; protocol encapsulation and decapsulationfunctions, and wherein the global memory mapper comprises: an addressmapping table, the address mapping table comprising: one or more rows inthe table, wherein each of the rows comprising: an ingress protocol; aningress start memory address; and an egress start memory address. 10.The method of claim 9 wherein the MPSC SOC transfers data between two ormore of the following interfaces: NVLink™, PCIe, Ethernet, RDMA, RoCEv2, RoCE v1, InfiniBand, OpenCAPI, Gen-Z, iWARP, FC-NVMe, ONFI.
 11. Asystem for interconnecting storage and networking devices via amultiprotocol switching system, comprising: a switch core, the switchcore creating data paths between attached devices, a first port protocolblock and a second port protocol block, each protocol block comprising amemory buffer for incoming data and outgoing data, protocolencapsulation and decapsulation functions, the first port protocol blockand the second port protocol block coupled to the switch core, aregister or memory table, comprising: ingress information, whichcomprise one or more of the following: ingress port number, ingress portidentification, ingress port protocol, egress information which compriseone or more of the following: egress port number, egress portidentification, egress port protocol for protocol encapsulation, egressinterface type, the register or memory table coupled to the first portprotocol block and the second port protocol block, a first networkingdevice coupled to the multiprotocol switching system, a second storagedevice coupled to the multiprotocol switching system, whereby the firstnetworking device sends data to the first port protocol block of themultiprotocol switching system, the first port protocol blockdecapsulates a first networking protocol, the resulting data is switchedto the second port protocol block, the second port protocol blockencapsulates the data into the protocol supported in the second portprotocol block and the data is sent out the egress port, the protocolsupported by the first port protocol block is different from theprotocol supported by the second port protocol block.
 12. The system ofclaim 11 whereby the networking protocol comprises one or more of thefollowing: InfiniBand, Ethernet, RDMA, TCP, IP, Fibre Channel, NVMe overFibre Channel, NVMe over TCP, iWARP, NVLink and the storage protocolcomprises one or more of the following: ONFI, PCIe, PCIe NVMe, OpenCAPI,Gen-Z, KVS.
 13. A method for interconnecting storage and networkingdevices via a multiprotocol switching system, comprising: a switch core,the switch core creating data paths between attached devices, a firstport protocol block and a second port protocol block, each protocolblock comprising a memory buffer for incoming data and outgoing data,protocol encapsulation and decapsulation functions, the first portprotocol block and the second port protocol block coupled to the switchcore, a register or memory table, comprising: ingress information, whichcomprise one or more of the following: ingress port number, ingress portidentification, ingress port protocol, egress information which compriseone or more of the following: egress port number, egress portidentification, egress port protocol for protocol encapsulation, egressinterface type, the register or memory table coupled to the first portprotocol block and the second port protocol block, a first networkingdevice coupled to the multiprotocol switching system, a second storagedevice coupled to the multiprotocol switching system, whereby themultiprotocol switching system (MPSC) receives a frame from the firstnetworking device coupled to the first port, the networking protocol isremoved from the incoming frame, the frame is sent through the switchcore to the second port protocol block, the second port protocol blockencapsulates the frame into a storage protocol, the frame is transmittedout the second port to the second storage device, the protocol supportedby the first port protocol block is different from the protocolsupported by the second port protocol block.
 14. The method of claim 13whereby the networking protocol may comprise one or more of thefollowing: InfiniBand, Ethernet, RDMA, TCP, IP, Fibre Channel, NVMe overFibre Channel, NVMe over TCP, iWARP, NVLink and the storage protocolcomprises one or more of the following: ONFI, PCIe, PCIe NVMe, OpenCAPI,Gen-Z, KVS.